Розробка зв`язкових таблиць і запитів до них на основі ER підходу

Міністерство освіти і науки України

Севастопольський національний технічний університет

Кафедра технічної кібернетики

Контрольна робота

З дисципліни "Інформаційне забезпечення систем управління"

Виконав: ст.гр. А-51з

Брусино С. Е.

Перевірив:

Шушляпін Є.А.

Севастополь

2008

1 Мета роботи

Отримати навички розробки зв'язкових таблиць і запитів до них на основі ER - підходу.

2 Постановка задачі

Завдання планування випуску виробів. розуміється три види ресурсів в кількостях 100, 100, 200 і два види виробів. Задані норми витрат Aij i-го ресурсу на одиницю j-го виробу - А11 = 2, А12 = 3, А21 = 1, А22 = 3, А31 = 3, А32 = 8. Ефективність випуску одиниці j-го виробу характеризується коефіцієнтами 30, 60 відповідно для першого і другого виробів. Визначити кількості деталей кожного типу, при яких сумарний показник ефективності, а кількість деталей другого типу не більше 13.

Завдання:

Проаналізувати словесну постановку задачі і на основі аналізу предметної області визначити сутності й атрибути для проектування бази даних ER-методом.

Визначити типи зв'язків між сутностями і обгрунтувати характеристику типів.

На основі правил ER-підходу визначити зв'язкові таблиці і внести зовнішні ключі.

На мові SQL записати один запит до бази даних з отриманою схемою.

Проаналізувати отриману базу даних з точки зору можливих аномалій при вставці, видаленні або оновленні даних.

3 ПРЕДМЕТНА ОБЛАСТЬ

Дане завдання являє собою предметну область, пов'язану з роботою промислового підприємства. Промисловий об'єкт, як і інше підприємство, являє собою складну систему із вхідними в неї підсистемами.

У постановці завдання виділяється всього одна підсистема, пов'язана з виробництвом необхідного асортименту товару з метою максимізації прибутку від продажів, тобто, відділ менеджменту та маркетингу.

При розробці інформаційного забезпечення для підприємства повинні враховуватися інформаційні потреби всіх підсистем системи підприємства. Однак при виконанні цієї лабораторної роботи обмежимося розробкою інформаційного забезпечення, що включає лише предметну область локального завдання, наведеної в пункті 2 цього звіту.

4 ВИЗНАЧЕННЯ СУТНОСТІ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ЇХ ХАРАКТЕРИСТИК

Проаналізувавши постановку задачі, можна виділити такі дві сутності: «виріб» і «ресурси», що йде на виготовлення. «Ресурси» в якості інформаційних атрибутів має тільки один - атрибут «кількість ресурсу». Ключем суті є «вид ресурсу», оскільки в таблиці «Ресурси» не може бути два записи з однаковими значеннями цього атрибута.

Сутність «Виріб» має атрибути «вид вироби», «кількість виробів». Ключем суті є «вид виробів» з тієї ж причини, що і для сутності «Деталі».

Якщо враховувати можливість зміни видів виробленої продукції підприємства, тобто зміна асортименту, перехід на нові види матеріалів для, то атрибути наведених вище сутностей будуть додаватися або змінюватися. Це має бути передбачено при проектуванні реальної бази даних підприємства, проте все ж таки необхідно розумно обмежувати предметну область проектованої бази даних.

5 ВИЗНАЧЕННЯ зв'язок між сутністю І ЇХ ХАРАКТЕРИСТИК

З огляду на те, що при проектуванні бази даних було введено лише дві сутності, то порядок зв'язку між ними бінарний.

Так як для виробництва одного виду виробу може витрачатися кілька видів ресурсів, а кожен ресурс, у свою чергу, може бути витрачений на виробництво декількох видів виробів, то в даному випадку має місце зв'язок n: m, то є «багато до багатьох». Далі необхідно визначити класи приналежності введених сутностей, для чого розглядаються ситуації, коли якийсь із видів ресурсу не бере участь у виробництві якого-небудь виду виробу або коли якийсь із видів вироби не вимагає при виробництві якоїсь з видів ресурсів.

Оскільки в описі предметної області описана можливість появи нових видів ресурсів і виробів, то в базі даних можуть зберігатися види ресурсів та виробів, які не беруть участь у виробництві і для яких норми витрат невідомі. Тому клас приналежності на обох кінцях необов'язковий.

Для визначення класів приналежності примикає до сутності «ресурси» кінця зв'язку розглянемо, чи можливі ситуації, коли якийсь із ресурсів не витрачається. Така ситуація можлива у випадку відсутності на підприємстві даного виду ресурсу, тому клас приналежності зв'язку необов'язковий.

Також можлива ситуація, коли в базі даних зберігаються вироби, випуск яких поки не виробляється і норми витрат ресурсів на які не відомі, тобто з видами ресурсів ці вироби тимчасово не пов'язані, значить клас приналежності необов'язковий.

На основі даних про прибуток від продажу одиниці виробу симплекс-методом, розглянутим у курсі ІВ, отримаємо оптимальний асортимент виробів.

Для даного випадку можна скласти діаграму ER-екземплярів і ER-типу.

На діаграмі ER-екземплярів зліва гуртками показують екземпляри однієї сутності, праворуч - примірники іншої сутності, а гуртки з'єднують між собою так, щоб вони відображали мають місце зв'язку між екземплярами сутності. Далі по побудованій діаграмі визначаються характеристики зв'язків: якщо від одного гуртка відходить багато ліній, то зв'язок має ступінь «багато», якщо існує гурток, не пов'язаний ні з чим іншим, то клас приналежності необов'язковий. За цим принципом перевіряються і права, і ліва сутності. Далі з урахуванням отриманих висновків, розглядають те, що може статися в перспективі, і приймають остаточне рішення.

Для нашого випадку діаграма ER-екземплярів буде мати вигляд, представлений на малюнку 5.2.

Малюнок 5.2 - Діаграма ER-примірників для проектованої БД

Аналіз зв'язків на Малюнок 5.5.2 показує, що діаграма не протирічить припущенням про ступінь зв'язку «багато до багатьох». З урахуванням же перспектив, про які йшла мова вище, і зліва і праворуч можуть бути гуртки, не пов'язані з кухлями на протилежній стороні.

Такий ретельний аналіз бази даних проводиться у випадку мінімізації обсягу бази даних і часу реалізації запитів, так як облік ступеня зв'язку і класу приналежності БД дозволяє зменшити обсяг БД і збільшити швидкість доступу до даних.

Діаграма ER-типу відображає сутності та зв'язку з їх характеристиками і зображується кількома способами. На малюнку 5.3 приведений один із способів відображення діаграми ER-типу для проектованої БД.

Малюнок 5.3 - Діаграма ER - типу для проектованої БД

6 ФОРМУВАННЯ СХЕМИ ПРОЕКТОВАНОЇ БД

Схеми БД мають два рівні: логічний і фізичний (концептуальний і внутрішній за іншою термінологією). На логічному (концептуальному) рівні визначають зв'язкові поля чи таблиці і розподіляють атрибути за таблицями. Останнє може виявитися і нетривіальним завданням, оскільки при описі предметної області можуть бути дані, які як би відносяться до декількох сутностей одночасно. У такому випадку, в залежності від зв'язку між сутностями, ці дані або включають в таблицю для однієї з сутностей, або поміщають у зв'язну таблицю.

На фізичному (внутрішньому) рівні задають типи значень атрибутів, довжини відповідних полів, стандартні та спеціальні правила цілісності. Стандартні правила цілісності реалізуються внутрішніми засобами СУБД, що підтримують поняття первинного та зовнішнього ключа. Спеціальні правила цілісності реалізуються у вигляді збережених процедур і тригерів - програмних засобів типу обробників подій, набори яких для різних типових ситуацій входять у інструментальні засоби сучасних (здебільшого промислових) СУБД. У Access обмежений набір тригерів доступний тільки в проектах.

Основним завданням при реалізації третього етапу є визначення базових таблиць для сутностей і формування зв'язків у вигляді додаткових полів базових таблиць або окремих зв'язкових таблиць.

Виходячи з правила № 6, логічна схема бази даних для розглянутого прикладу буде містити три таблиці - дві базові для сутностей «Ресурси» і «Виріб» і одну зв'язну, яку назвемо «Вироби-ресурси». Ці таблиці, наведені нижче, крім усього іншого, містять позначення (PK) і (FK) для первинних і зовнішніх ключів відповідно.

Таблиця 6.1 - РЕСУРСИ

Таблиця 6.2 - ВИРОБИ

Таблиця 6.3 - ІздеДІЯ-РЕСУРСИ

Для переходу до фізичного рівня схеми визначимо типи і розміри (формати) полів, маючи на увазі реалізацію БД в Access.

Цю базу можна розширювати, вводячи в неї нові види виробів і ресурсів. Так як база методологічно правильно спроектована, вона вільна від аномалій включення, видалення і оновлення даних, має відносно невелику надмірність (за рахунок повторення даних у зовнішніх ключах), до неї можуть бути застосовані вбудовані в СУБД засоби контролю цілісності даних.

На цьому процес проектування БД можна вважати завершеним.

7 РЕАЛІЗАЦІЯ ПРОЕКТОВАНОЇ БД

Подальша робота пов'язана з реалізацією БД в обраної СУБД. У процесі реалізації повинні бути створені запити, екранні форми, звіти і інші об'єкти бази даних. Цей етап пов'язаний більше з розробкою додатків для конкретних користувачів, хоча в широкому сенсі його можна включати і в процес проектування бази даних.

Розроблена база даних включає наступні об'єкти: таблиці «Меблі», «Норми витрат», «Матеріал»; запити «Запрос1», «Запрос2»; форми «Меблі», «Норми витрат», «Норми витрат 1», «Матеріал»; звіт «Сумарний прибуток». Нижче наведені листинги вікон конструкторів для перерахованих вище об'єктів.

Малюнок 7.1 - Таблиця МАТЕРІАЛ

Малюнок 7.2 - Таблиця МЕБЛІ

Малюнок 7.3 - Таблиця НОРМИ ВИТРАТ

Малюнок 7.4 - Запит 1.

Малюнок 7.5 - Запит 2.

Текст запиту 2 на мові SQL має вигляд:

SELECT Sum ([Ціна продажу] * [Кількість виробів]) AS [Максимальна прибуток]

FROM Меблі;

Малюнок 7.6 - Форми проектованої БД

Малюнок 7.7 - Звіт Сумарний прибуток

Висновки

У ході виконання лабораторної роботи була виділена предметна область для створення інформаційної системи з метою задоволення запитів про оптимальний вирішенні завдання та оптимальному значенні критерію, був складений набір умов, за яких буде функціонувати проектована інформаційна система.

Були визначені сутності та зв'язку виділеної предметної області та їх характеристики, результат представлений у вигляді діаграм ER-екземплярів і ER-типу. Дані діаграми приведені у пункті 5 цього звіту.

Був розроблений проект на логічному і фізичному рівнях з використанням ER-підходу, результат проектування представлений у вигляді логічної БД, наведеної в пункті 6 цього звіту.

Були створені таблиці спроектованої БЛ і її фізична схема в Access за допомогою стандартних засобів контролю цілісності. Були створені запити у відповідності з варіантом завдання. Запит, створений для знаходження рішення не буде коректно працювати для іншого набору даних (інша умова задачі), і дає достовірну інформацію при оновленні або розширенні даних. За запитом був створений звіт. Зовнішній вигляд таблиць, запитів і звіту наведено на малюнках пункту 7 цього звіту.